<HTML
><HEAD
><TITLE
>What will Perl 6 be like?</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
REL="HOME"
TITLE="Perl 6"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Where are we now?"
HREF="x115.html"><LINK
REL="NEXT"
TITLE="Where next?"
HREF="x228.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Perl 6: The story so far</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x115.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x228.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN130"
>What will Perl 6 be like?</A
></H1
><P
>Again from Larry's talk at ALS, here is his list of constraints on the
development of Perl 6:</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN133"
>Constraints on Perl 6 (Larry's list)</A
></H2
><P
></P
><UL
><LI
><P
>Can Larry understand it? </P
></LI
><LI
><P
>Do people really need the new feature? </P
></LI
><LI
><P
>Can we implement it efficiently and robustly? </P
></LI
><LI
><P
>Does it preclude translation from Perl 5? </P
></LI
><LI
><P
>Does the utility grow faster than the complexity? </P
></LI
><LI
><P
>Does the size grow slower than Moore's Law </P
></LI
><LI
><P
>Must take time to maintain Perl 5 </P
></LI
><LI
><P
>Must take time to design Perl 6 right </P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN152"
>Skud's psychic powers predict the future (with help from Larry's talk)</A
></H2
><P
></P
><UL
><LI
><P
>Perl will still be Perl</P
><P
></P
><UL
><LI
><P
>TMTOWTDI ("There's more than one way to do it")
	-- just because one Perl language construct duplicates the
	functionality of another is not sufficient reason to avoid it.</P
></LI
><LI
><P
>Make easy things easy, hard things possible --
	if a feature achieves this, it is in keeping with the Perl
	spirit and is likely to be considered for inclusion.</P
></LI
><LI
><P
>Perl is not Python, Java, C, BASIC, COBOL,
	Lisp... and will not become any of these, despite the loud
	arguments put forward by some proponents of these languages
	during the RFC process</P
></LI
><LI
><P
>... but it should be easy for people from those
	languages to pick up</P
></LI
><LI
><P
>May also be easier to connect directly to those
	languages (e.g. Inline.pm, cleaner XS replacement,
	etc.)</P
></LI
></UL
></LI
><LI
><P
>Language changes</P
><P
></P
><UL
><LI
><P
>Death to global variables! (especially
	punctuation vars such as <TT
CLASS="LITERAL"
>$/</TT
>); these are
	likely to be converted to some kind of OO interface.</P
></LI
><LI
><P
>Deprecated features removed.  For instance, the
	use of <TT
CLASS="LITERAL"
>'</TT
> as a synonym for
	<TT
CLASS="LITERAL"
>::</TT
> will die a peaceful death of old age</P
></LI
><LI
><P
>Non-critical builtins move out to modules,
	including formats, shared memory functions,
	<TT
CLASS="LITERAL"
>gethostbyname</TT
> and friends, etc</P
></LI
><LI
><P
>Easier and safer OO programming</P
></LI
><LI
><P
>Easier functional programming</P
></LI
><LI
><P
>No more typeglobs (but none of their functionality lost)</P
></LI
><LI
><P
>Filehandles become objects</P
></LI
><LI
><P
>Easier interpolation of complex expressions</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>	print "The answer is $obj-&#62;answer()"; </PRE
></TD
></TR
></TABLE
></LI
><LI
><P
>Optional typing of scalars (int, float, etc)</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>	my int $answer = 42; 
	my int @array = (1, 2, 3);</PRE
></TD
></TR
></TABLE
></LI
><LI
><P
>Better subroutine parameter specification mechanism</P
></LI
><LI
><P
>A switch statement, based on Damian Conway's
	excellent (and very Perlish) suggested implementation</P
></LI
><LI
><P
>wantarray() becomes a more generic want()</P
></LI
></UL
></LI
><LI
><P
>Standard library changes</P
><P
></P
><UL
><LI
><P
>Greater consistency</P
></LI
><LI
><P
>More applications development support: web, XML,
	CORBA, ???</P
></LI
><LI
><P
>Some stuff moved from the core to the library:
	date/time, shm*, formats, etc</P
></LI
></UL
></LI
><LI
><P
>Internals changes</P
><P
></P
><UL
><LI
><P
>More modular</P
></LI
><LI
><P
>Easier to maintain</P
></LI
><LI
><P
>Much easier to extend</P
></LI
><LI
><P
>Better garbage collection</P
></LI
><LI
><P
>We'll know more when we start on detailed
	design and implementation</P
></LI
></UL
></LI
><LI
><P
>Licensing changes</P
><P
></P
><UL
><LI
><P
>Possible rewrite of the Artistic
	License</P
></LI
></UL
></LI
></UL
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x115.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x228.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Where are we now?</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Where next?</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>